With the rise of the popularity of the Internet, many forms of digital entertainment have crossed over from their traditional distribution medium to that of Internet. One notable example is radio broadcasting, where technology in the past decade has enabled listeners from around the world with access to the Internet to select the desired content and hear radio programs from their personal computers. While digital entertainment such as radio broadcasting has gained popularity, the genre is limited in the sense that the action is uni-directional, i.e. entertainment content flowing in one direction only from the provider to the users. Although this is convenient, the format does not fit well with the intrinsic nature of the Internet, which always has involved a high degree of interaction. The most basic example of a bi-directional form of communication with respect to the Internet is the interaction of users in clicking a link on a page in the World Wide Web to select content to be viewed.
Interactive online digital entertainment has gained ground on many fronts in recent years, especially with respect to video gaming. For example, users can login to certain websites to first find an opponent and then play a game of chess in the virtual world. As a human player will be competing against another human player, the form of communication is bi-directional. However, not all video games can be played online. For a game of chess where time to make a move does not have an immediate and consequential effect on the outcome (also called a twitch game), players obviously have ample time to contemplate the next move, counter-move, game strategy and so on. However, in a majority of real-time video games, time needed to make a decision and act upon that decision is relatively short so that players involved feel a sense of realism. In such a real-time game, action must occur in close proximity in every aspect thereof to real life events. Real-time action is a must for the action genre (e.g., fighting games), simulation genre (e.g., flight simulators) and sport genre (e.g., baseball games).
With respect to video games played by a single player (either on a console or personal computer (PC)), the video game program determines how best to mimic real life. On the other hand, with respect to games played over the Internet, game programmers must consider network latency that will delay an action, or, in a multiplayer setting, display a different progression of the same game to players based on a variety of criteria. The time difference of the display to respectively different players can be extremely small, perhaps no more than 500 ms (equivalent to approximately one half of a second), which may seem like a relatively insignificant passage of time; however, in a real-time game such a time difference may be determinative of game outcomes.
Network latency involves the time needed for packets of data (e.g., the information related to a character's action) to travel from a user's computer to the game server and then from the game server to the rest of the users. Ideally, if all users have the same network latency, there would be no issue as all events would just be delayed by the same amount of time. However, due to different geographical locations, as well as quality of Internet connection services, each user is likely to have a different latency. Thus, each user would be looking at a different point in time in the game, which would prevent crucial judgments (e.g., determining at a given moment the right strategy to defend an offensive play in a football game) from taking place and thereby would effectively eliminate the realism in the game.
Network latency has been addressed, for example, in U.S. Pat. No. 5,695,400 to Fennell, Jr. et al.; U.S. Pat. No. 5,775,996 to Othmer et al.; U.S. Pat. No. 5,820,463 to O'Callaghan; U.S. Pat. No. 5,838,909 to Roy et al.; U.S. Pat. No. 5,899,810 to Smith; U.S. Pat. No. 5,974,442 to Adams; U.S. Pat. No. 6,006,254 to Waters et al.; U.S. Pat. No. 6,012,096 to Link et al.; U.S. Pat. No. 6,025,801 to Beitel; U.S. Pat. No. 6,042,477 to Addink; U.S. Pat. No. 6,304,902 to Black et al.; U.S. Pat. No. 6,345,297 to Grimm et al.; U.S. Pat. No. 6,415,317 to Yelon et al.; U.S. Pat. No. 6,475,090 to Roelofs; each of which is incorporated herein by reference in its entirety.
FIG. 1 illustrates the conventional way to compensate for network latency, in which the main idea is to build in a buffer where everyone is delayed by a set amount of time (in this case 500 milliseconds (ms)) minus the respective network latency time before any action occurs on the screen. More particularly, in the prior art network latency solutions, an intentional delay is built into the game so that each player of the game sees the start of the motion at the same time. During the game or when players log in, the server detects an average ping time for each player (ping time is defined herein as the time required for a packet of data to travel from a player's computer to a predetermined server, which in this case would be a game server). Typically, if the ping time is above 400 ms, the player will not enjoy a smooth game due to the fact that the player's response to other player's actions will always be late.
Referring now to FIG. 1, the default allowance is 500 ms, player X has an average ping time of 300 ms and player Y has an average ping time of 100 ms. Player X initiates an action (throwing a ball) by clicking his mouse at t=0 ms. Player Y is the intended receiver of the ball thrown by player X. The server receives the signal from player X at t=300 ms (note that other players in the game do not at this instant know that X has initiated the throwing action). The server then calculates the difference between the player's average ping time and the default allowance, thus in this case 500 ms−300 ms=200 ms, which is the value of the intentional buffer. The server sends signals to other players in the game at t=300 ms, including player Y who has a player-specific buffer of 100 ms. The server then calculates the intentional buffer for Y (500 ms−100 ms=400 ms). Thus, as shown in FIG. 1, 800 ms elapses before both X and Y see that the ball is thrown. The timeline described above can be summarized as follows:    t=0 ms [X clicks mouse to initiate action]    t=300 ms [Server receives signal from X]    t=400 ms (300+100) [Y receives signal from server that X has initiated action and that the action will be shown 400 ms later]    t=600 ms (300+300) [X receives signal from server that action will be shown 200 ms later]    t=800 ms (300+100+400 or 300+300+200) [both X and Y see the throwing action]
The above-described process is complicated tremendously if the network latency of player X is higher than a certain threshold, say, 500 ms. In such a case, the whole solution would be rendered useless because the delay in the action would be too great (i.e., more than 1 second). Thus, various methods have been proposed to address this problem.
For example, U.S. Pat. No. 6,475,090 to Roelofs is directed to in-game factors to compensate for network latency. A method is provided for compensating for high-latency computer clients in a multi-player electronic game played on a plurality of terminals connected by a network. A latency value is determined for computer clients operating the terminals, after which a latency compensation factor is determined from the latency value for each client computer. The playing modality of a client computer can then be adjusted based on the latency compensation factor. The compensation techniques are applied during the playing of the game time via the previously constructed latency compensation curve. For example, a compensation curve may be employed whereby a player would be afforded a compensation mechanism commensurate with his measured latency. The compensation may, for example, provide the player with an increase in speed to enable him to compensate for his delay. There is, however, no buffering involved.
U.S. Pat. No. 6,304,902 to Black et al. is directed to a method and system for determining network latency between clients in a computer network having at least two clients connected thereto in a manner that reduces network traffic at any given time. Each client determines the network latency between each other client via a ping, response, and response-response protocol. To this end, a first client places first time information such as a time stamp into a (ping) data packet and sends the packet to the second client, who places second time information into the packet and sends the packet as a response packet back to the first client. The first client determines a first network latency based on its current time and the first time information returned in the response packet. The first client then sends the packet back to the second client as a response to the response packet. The second client determines a second latency based on the current time information at the second client and the second time information received in the response-response packet. For multiple clients such as in a gaming zone environment, each local client sorts the IP addresses of the other remote clients into sets of clients, and pings the remote client or clients in each set once per predetermined period, thereby distributing the pinging operation to balance incoming and outgoing network traffic. More particularly, this solution matches players in proximity (and thereby lower network latency) to play each other, thus exempting the possibility that network latency may affect gameplay during the game. However, this method only allows peer-to-peer (where action information in the form of data packets are sent from one player to other player(s)), not server/client, matches to take place.
Importantly, the above-described solutions do not permit a potential third party to intervene in the gameplay. Team sport games such as baseball, American football, soccer, ice hockey and basketball, for example, by their nature require multiple players to engage in possession of the game ball. While the aforementioned solutions address compensating network latency, the pertinent architecture focuses on one-on-one gameplay. The particular problem related to a multiplayer game having a TCP/IP server/client structure (in contrast to peer-to-peer structure), in which a solution to latency compensation (due to an event that has an immediate and consequential effect on another (or next) event) is required, has heretofore yet to be provided.
Thus, with respect to multiplayer online games involving simultaneous participation of users positioned at different locations (i.e., users distanced remotely from one another, perhaps even in different countries), wherein the structure is TCP/IP server/client, there exists a need for an invention that can effectively overcome problems posed by network latency.